The Microsoft® Corporation has developed a platform-independent, distributed, object-oriented system for creating binary software components that can interact. This system is commonly referred to as Component Object Model or COM, and is the foundation technology for Microsoft's OLE (compound documents), ActiveX® (Internet-enabled components), as well as others.
To understand the COM concept, it is note that COM is not an object-oriented language but a standard. Further, COM does not specify how an application should be structured. Language, structure, and implementation details are left to the application programmer. COM on the other hand does specify an object model and programming requirements that enable COM objects (also called COM components, or simply objects) to interact with other objects. The “objects” can be within a single process, in a variety of processes, and can even be on remote machines. They can even be written in different languages, and may be structurally quite dissimilar. Thus, COM is referred to as a binary standard and applies after a program has been translated to binary machine code.
The only language requirement for COM is that the code defining the COM be generated in a language that can create structures of pointers and either explicitly or implicitly, call functions through pointers. For example, object-oriented languages such as Microsoft® Visual C++® and Smalltalk provide programming mechanisms that simplify the implementation of COM objects, but languages such as C, Pascal, Ada, Java, and even BASIC programming environments can also create and use COM objects.
In general, a software object is made up of a set of data and the functions that manipulate the data. A COM object on the other hand is one in which access to an object's data is achieved exclusively through one or more sets of related functions. These function sets are called interfaces, and the only way to gain access to an interface is through a pointer to the interface. Besides specifying the basic binary object standard, COM defines certain basic interfaces that provide functions common to all COM-based technologies, and it provides a small number of API functions.
The concept of using COM objects and interfaces allows objects to interact across process and machine boundaries as easily as within a single process. The use of such common modules enables the manipulation of data associated with an object through an interface on the object. COM uses the word interface in a sense different from that typically used in Visual C++ programming. A C++ interface refers to all of the functions that a class supports and that clients of an object can call to interact with it. A COM interface refers to a predefined group of related functions that a COM class implements, but a specific interface does not necessarily represent all the functions that the class supports. Referring to an object implementing an interface means that the object uses code that implements each method of the interface and provides COM binary-compliant pointers to those functions to the COM library. COM then makes those functions available to any client who asks for a pointer to the interface, whether the client is inside or outside of the process that implements those functions.
The COM concept makes a fundamental distinction between interface definitions and their implementations. An interface is actually a contract that consists of a group of related function prototypes whose usage is defined but whose implementation is not. These function prototypes are equivalent to pure virtual base classes in C++ programming. An interface definition specifies the interface's member functions and what they must do. There is no actual implementation associated with an interface. An interface implementation on the other hand is the code supplied to carry out the actions specified in an interface definition.
Simple objects support only a single interface. More complicated objects, such as embeddable objects, typically support several interfaces. Client applications have access to a COM object only through a pointer to one of its interfaces, which, in turn, allows the client application to call any of the methods that make up that interface. These methods determine how a client can use the object's data.
An important aspect of the COM concept is how client applications and servers interact. A COM client application is whatever code or object gets a pointer to a COM server and uses its services by calling the methods of its interfaces. A COM server is any object that provides services to clients; these services are in the form of COM interface implementations that can be called by any client that is able to get a pointer to one of the interfaces on the server object. There are two main types of servers, and can be classified as in-process and out-of-process servers. In-process servers are implemented in a dynamic linked library (.DLL), and out-of-process servers are implemented in an executable file (.EXE). .DLL and .EXE files will be recognized by anyone familiar with Microsoft® Windows® software. Out-of-process servers can reside either on the local machine or on a remote machine. In addition, the COM concept provides a mechanism that allows an in-process server (a .DLL) to run in a surrogate .EXE process to gain the advantage of being able to run the process on a remote machine.
A well-known example of the COM concept with respect to an .EXE program is “spell checker” in MS Office. Spell Checker is a single software component that can be called on by the word processing program or any other of the programs in MS Office.
A dynamic-link library (.DLL) on the other hand, is a module that contains functions and data that can be used by another module (application or .DLL).
For example, a .DLL can define two kinds of functions: exported and internal. The exported functions may be called by other modules, as well as from within the .DLL where they are defined. Internal functions are typically called only from within the .DLL where they are defined. Although a .DLL can export data, its data is generally used only by its functions. However, there is nothing to prevent another module from reading or writing that address.
.DLLs provide a way to modularize applications so that functionality can be updated and reused more easily. They also help reduce memory overhead when several applications use the same functionality at the same time, because although each application gets its own copy of the data, they can share the code.
The Windows® application programming interface (API) is implemented as a set of dynamic-link libraries, so any process that uses the Windows® API uses dynamic linking.
Dynamic linking allows a module to include only the information needed to locate an exported.DLL function at load time or run time. Dynamic linking differs from the more familiar static linking, in which the linker copes a library function's code into each module that calls it.
A .DLL can be called during loading or running a program. In load-time dynamic linking, a module makes explicit calls to exported .DLL functions as if they were local functions. This requires linking the module with the import library for the .DLL that contains the functions. An import library supplies the system with the information needed to load the .DLL and locate the exported .DLL functions when the application is loaded. The threads of the process that called the .DLL can use handles operated by a .DLL function. Similarly, handles opened by any thread of the calling process can be used in the .DLL function. The .DLL uses the stack of the calling thread and the virtual address space of the calling process. The .DLL allocates memory from the virtual address space of the calling process.
Programming models and constructs using COM allow COM clients and servers to work together across the network, not just within a given machine. This enables existing applications to interact with new applications and with each other across networks with proper administration, and new applications can be written to take advantage of networking features. It is not necessary for COM client applications to be aware of how server objects are packaged. For example, they may be packaged as in-process objects (in .DLLs) or as local or remote objects (in .EXEs). The COM concept is designed for location transparency that extends across a network. This allows applications written for single machines to run across a network and provides features that extend these capabilities and adds the security necessary in a network. More specifically, there are nearly 200 Microsoft® Windows® defined COM interfaces and tens of thousands COM components overall. In most cases, these generic interfaces can be re-used. However, some applications have specific requirements that make it desirable or necessary to define specific object interfaces.
The Microsoft® Windows® registry is the system database for Windows® operating systems. It contains information about the configuration of system hardware and software as well as about users of the system. Any Windows®-based program can add information to the registry and read information back from the registry. While writing a new program, programmers often search the registry for interesting components to use.
Thus, the registry maintains information about all the COM objects installed in the system. Whenever an application creates a COM component, the registry is consulted to resolve either the CLSID (Class's ID) or ProgID of the component into the pathname of the server .DLL or .EXE that contains it. A CLSID is a generated 128 bit unique identifier or UUID as defined by the DCE organization. A UUID is a randomly-generated unique ID, and an interface ID or IID as well as a CLSID. The ProgID is a string identifier that the client program can use to resolve possible CLSID's. The COM system may use any of these three ID's (CLSID, IID and ProgID). After determining the component's server, Windows® either loads the server into the process space of the client application (in-process components) or starts the server in its own process space (local and remote servers). The server creates an instance of the component and returns to the client a reference to one of the component's interfaces.
Additional information concerning Mircosoft® COM system may be found on the internet at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/comportal—3qn9. asp, and http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dynamic_link_libraries.asp.